Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Set org.apache.core as the jkd9 automatic module name for camel-core #2007

Closed
wants to merge 1 commit into from

Conversation

johnpoth
Copy link
Member

@johnpoth johnpoth commented Oct 5, 2017

This will be useful for people wanting to use Java 9's module system with camel-core.

From Mark Reinhold's recommendation and common adoption, the module name should correspond to the principal exported API package:

Strongly recommend that all modules be named according to the reverse
Internet domain-name convention. A module's name should correspond
to the name of its principal exported API package, which should also
follow that convention. If a module does not have such a package, or
if for legacy reasons it must have a name that does not correspond to
one of its exported packages, then its name should at least start
with the reversed form of an Internet domain with which the author is
associated.

Thanks!

@@ -5174,6 +5174,7 @@
<Karaf-Info>Camel;${project.artifactId}=${project.version}</Karaf-Info>
<_versionpolicy>${camel.osgi.import.default.version}</_versionpolicy>
<_failok>${camel.osgi.failok}</_failok>
<Automatic-Module-Name>${camel.automatic.module.name}</Automatic-Module-Name>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens here if other components do not have that option, is that value empty in the manifest file or ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @davsclaus , yes if it's not defined there will be no value in the manifest (there won't even be a 'Automatic-Module-Name' key)

@@ -115,6 +115,7 @@
</camel.osgi.activator>
<!-- do not skip any tests by default -->
<platform.skip.tests/>
<camel.automatic.module.name>org.apache.camel</camel.automatic.module.name>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it not be org.apache.camel.core

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh reverse internet domain name then its: core.camel.apache.org

Can we double check this to be sure?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @davsclaus the camel website is currently at http://camel.apache.org/ so our reverse internet domain is 'org.apache.camel' which also happens to be our principal exported API package. Hence I propose 'org.apache.camel' as the automatic module name but 'org.apache.camel.core' is fine with me. Here are some other projects for comparison:

Mapstruct -> org.mapstruct
Mockito -> org.mockito
RxJava -> io.reactivex.rxjava2

For our Camel components, dataformats and spring starters we can set the automatic module name to the primary package. We can also set the name to 'org.apache.camel.X' for everything under components/X and 'org.apache.camel.springboot.X' for all our spring starters to shorten the names a little and for consistency. I have a preference for the second option.

Let me know what you think,

John.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I suggest we wait with this until 2.21 release so we can debate in the community what the naming should be.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davsclaus
Copy link
Contributor

Lets close this for now - we are on JDK8 and JDK9 is already EOL and same thing happens with JDK10 that is short lived.

@davsclaus davsclaus closed this Mar 22, 2018
Croway pushed a commit to Croway/camel that referenced this pull request Mar 14, 2024
[ENTESB-19409] Upgrade to json-smart 2.4.8
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants